RESERVATION PROXY FUNCTION 
SUPPORTING FILTERING OF MULTICAST TRAFFIC 
IN PACKET-BASED COMMUNICATION SYSTEMS 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This invention is related to U.S. Patent Application Serial No. 09/891,645, 
titled "Methods for Managing Bandwidth in a Packet-Based Communication 
System Incorporating a Reservation Proxy Function," filed June 26, 2001; U.S. 
Patent Application Serial No. 09/728,621, titled "Method for Managing 
Bandwidth in a Packet-Based Communication System," filed December 1, 2000; 
and U.S. Patent Application Serial No. 09/728,620, titled "Method for Managing 
Bandwidth in a Packet-Based Communication System Using Call Unit 
Reservations," filed December 1, 2000, each assigned to the assignee of the 
present invention and incorporated herein by reference in their entirety. 

FIELD OF THE INVENTION 

This invention generally relates to packet-based communication systems 
and, in particular, to a method of providing admissions control in a packet-based 
communication system using a reservation proxy function. 

BACKGROUND OF THE INVENTION 

Communication systems typically include a plurality of communication 
units, such as mobile or portable radio units, dispatch consoles and base stations 
(sometimes called base site repeaters) that are geographically distributed among 
various base sites and console sites. The radio units wirelessly communicate with 
the base stations and each other using radio frequency (RF) communication 
resources, and are often logically divided into various subgroups or talkgroups. 

Communication systems are often organized as trunked systems, where the 
RF communication resources are allocated on a call-by-call basis among multiple 
users or groups. Wide-area trunked systems are sometimes organized into a 
plurality of "zones," wherein each zone includes multiple sites and a central 
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controller or server ("zone controller") for allocating communication resources 
among the multiple sites. The zone controller(s) may reside within a single device 
or multiple devices and may be located at a fixed equipment site or may be 
distributed among various base sites. The RF resources may comprise, for 
5 example, narrow band frequency modulated channels, wideband modulated 
signals, broadband modulated signals, time division modulated slots, carrier 
frequencies, frequency pairs, or generally any medium for communicating 
information, such as voice, video, or data traffic ("payload information") or 
control signaling ("control information") to and from participating communication 

1 0 devices over wireless link(s). 

In recent years, communication systems have been implemented using 
packet-switched technology where information that is to be communicated 
between endpoints is divided into packets and transported by various routers 
forming an Internet Protocol (IP) network. Packet-switched networks are 

1 5 sometimes called "connectionless" networks because they do not provide 
dedicated bandwidth or circuits between endpoints, but rather permit 
communications between multiple endpoints to proceed concurrently over shared 
paths or connections. The endpoints (or "hosts" in IP terminology) may comprise, 
for example, base stations, consoles, routers, zone controllers, and in some 

20 instances, wireless mobile or portable radio units in different zones that desire to 
receive packets for a particular call. In such systems, the participating hosts send 
Internet Group Management Protocol (IGMP) Join messages to attached routers, 
causing the routers of the network to create a spanning tree of router interfaces for 
distributing packets for the call. 

25 Due to the "connectionless" nature of IP packet-based networks, 

it is possible to over-subscribe certain links including, but not limited to, inter- 
zone links between multiple hosts. Generally, in any packet-based system, over- 
subscription of link(s) causes delays in transport of IP packets that adversely 
effect the quality of service of the network. The problem is most acute in large 

30 systems including multiple hosts distributed among several sites and/or zones. In 
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such systems, inter-zone links between remote hosts are usually leased by 
communication system customer(s). Understandably, customers demand a certain 
quality of service and are more willing to occasionally queue (or "busy") inter- 
zone calls due to insufficient resources than to pay extra recurring costs to 
5 overpro vision these links to accommodate peak traffic loads. Accordingly, there 
is a need for a method of admission control in an IP packet-based communication 
system that provides for establishing calls over shared links of an IP network 
without exceeding available bandwidth. 

One manner of addressing these needs is described in related patent 

10 application 09/891,645, wherein reservations of bandwidth are established 

dynamically (i.e., on a call-by-call basis) for certain links by a certain host devices 
(termed reservation proxy elements, or RPEs) on behalf of other participating 
hosts (e.g., base stations, etc.) that may require use of bandwidth. The 
reservations of call units are established by the RPEs using standard ReSerVation 

1 5 Setup Protocol (RSVP) signaling using multicast group address(es) that are used 
for actual calls. The RPEs join a multicast group address that is to be used for a 
call and exchange RSVP signaling messages across one or more inter-zone, 
packet network links to reserve communication resources for the call on behalf of 
participating devices in various zones. The RPE function may reside within the 

20 zone controllers or separate infrastructure device(s) of different communication 
zones. 

Advantageously, the reservation proxy operation enables bandwidth 
reservations made by the RPEs to be exploited by other hosts of the network 
without the need for separate RSVP transactions, and hence without additional 

25 network loading. A problem that arises, however, is that the operation described 
in the 09/891,645 application does not provide for the RPEs to specify any 
filtering of multicast traffic. Consequently, the RPEs (while joined to the 
multicast group address) will continue to receive all payload and control 
information directed to the multicast group address even though, generally, it is 

30 undesirable for the RPEs to receive payload information since this negatively 
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impacts in control processing capacity. Optionally, the RPEs may leave the 
multicast group address after establishing the RSVP reservations so as to 
discontinue receiving payload information, but this will also result in 
discontinuing control information that may be necessary for the RPEs to perform 

5 further resource management or control functions for the call. 

For example, roaming of radio units between different communication 
zones may occur such that new links need to be established (or old links torn 
down) during a call. Typically, the location of the radio units is tracked by zone 
controller(s) and, if necessary, changes are communicated to other zone 

1 0 controllers and/or RPEs via control messages. If any RPEs were to leave the 

multicast group address after establishing the RSVP reservations for a particular 
topology, they would be unaware of the new topology and thus would be unable to 
accommodate resource management functions for the new topology. This 
problem would occur whether the RPEs reside within one or more zone 

1 5 controllers (e.g., upon certain zone controller(s) no longer being able to track 

location, or no longer exchange control messages with other zone controllers) or 
within separate devices (e.g., upon the RPEs no longer receiving control 
information from zone controllers). 

Accordingly, there is a need for a reservation proxy operation whereby 

20 RPEs make bandwidth reservations on behalf of other hosts in the network, but 
which allows the RPEs to specify filtering of multicast traffic. Advantageously, 
the reservation proxy operation will enable RPE/zone controllers to receive 
desired control information for the duration of the call without being encumbered 
by undesired payload information. The present invention is directed to addressing 

25 these needs. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other advantages of the invention will become apparent 
upon reading the following detailed description and upon reference to the 
drawings in which: 

FIG. 1 shows a multi-zone packet-based communication system 
incorporating a reservation proxy function within respective zone controllers 
according to one embodiment of the invention; 

FIG. 2 is a block diagram useful for illustrating an RSVP message 
sequence between RPEs and routers of a multi-zone packet-based communication 
system; 

FIG. 3 is a flowchart showing steps performed by zone controller/RPE(s) 
to set up a prospective multicast call according to one embodiment of the 
invention; 

FIG. 4 is a flowchart showing steps performed by a controlling zone 
controller/RPE(s) upon ending of a multicast call according to one embodiment of 
the invention; and 

FIG. 5 is a flowchart showing steps performed by zone controller/RPE(s) 
to add new participating zones for a call in progress according to one embodiment 
of the present invention. 

DESCRIPTION OF PREFERRED EMBODIMENTS 

FIG. 1 shows by way of example and not limitation, a packet-based 
communication system 100 comprising a plurality of base sites 102 organized into 
a plurality of zones ("Zone 1" through "Zone 4"). For convenience, the base sites 
102 are shown only at Zone 1, although it will be understood that base sites are 
also at Zones 2, 3 and 4. The base sites 102 include base stations 106 for 
communicating via RF resources with wireless communication units (e.g., 
communication units 156-163) within their respective coverage areas, which 
communication units may roam from site to site and from zone to zone. 
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The base sites 102 are logically coupled, via router elements 104 ("base 
site routers") to router elements 116, 118, 120, 122 ("core routers") associated 
with their respective zones. The core routers are logically connected via packet 
network (inter-zone) links 148, 150, 152, 154. The core routers 116, 118, 120, 
122 are connected to respective zone controllers 124, 126, 128, 130 that perform 
call processing and mobility management functions for communication units 
within their respective zones. 

In the preferred embodiment, the zone controllers 124, 126, 128, 130 
further perform reservation proxy functions associated with the respective zones 
1-4. Alternatively or additionally, reservation proxy functions may be 
incorporated within separate physical devices including, but not limited to 
console(s), call logger(s) and/or other infrastructure device(s) that may be 
included within the communication system 100. For convenience, device(s) 
incorporating reservation proxy functionality will be referred to as reservation 
proxy elements ("RPEs"). In one embodiment, as will be described in greater 
detail in relation to FIG. 3, the RPEs use RSVP signaling to dynamically obtain 
reservations of bandwidth on one or more of the inter-zone links 148, 150, 152, 
154 for a prospective call or, as described in relation to FIG. 5, to obtain 
bandwidth reservations for a link to a new zone. The RSVP message sequence is 
described generally in relation to FIG. 2. 

The base site routers 104 and the core routers 1 16, 1 18, 120, 122 are 
functional elements that may be embodied in separate physical devices or 
combinations of such devices, which devices comprise specialized or general 
purpose computing devices configured to receive IP packets from a particular host 
in the communication system 100 and relay the packets to another router or 
another host in the communication system 100. Packets may be distributed 
between zones using sparse mode routing protocols such as the Core Based Tree 
(CBT) protocol and the Protocol Independent Multicast - Sparse Mode (PIM-SM) 
protocol, dense mode routing protocols such as the Distance Vector Multicast 
Routing Protocol (DVMRP), Protocol Independent Multicast - Dense Mode (PPM- 
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DM) and the Multicast Open Shortest Path First (MOSPF) protocol, or virtually 
any other protocol suitable for transporting packets between hosts of the 
communication system 100. 

In one embodiment, the base stations 106, base site routers 104, core 

5 routers 1 16, 1 18, 120, 122, and zone controller/RPEs 124, 126, 128, 130 of the 
communication system 100, as well as any consoles or wireline devices that may 
be included the communication system 100 comprise IP host devices that are able 
to send and receive IP packets or datagrams between other host devices of the 
network. Recent advances in technology have also extended IP host functionality 

10 to wireless communication units, in which case the wireless communication units 
156-163 may comprise host devices as defined herein. Each host device has a 
unique IP address. The host devices include respective processors (which may 
comprise, for example, microprocessors, microcontrollers, digital signal 
processors or combination of such devices) and memory (which may comprise, 

15 for example, volatile or non-volatile digital storage devices or combination of 
such devices). 

Generally, any host device, including base stations, consoles, zone 
controllers, and in some instances, wireless mobile or portable radio units in 
different zones that desires to receive packets for a particular call, sends Internet 

20 Group Management Protocol (IGMP) Join messages to their attached routers, 
indicating a desire to join a multicast group address for the call. The routers of 
the network, in turn, create a spanning tree of router interfaces for distributing 
packets for the call. 

In one embodiment, the zone controller/RPEs utilize the IGMPv3 protocol 

25 (defined in the IETF draft draft-ietf-idmr-igmp-v3-08.txt) to join the multicast 
group address associated with the call. The IGMPv3 protocol permits certain 
host(s) to specify senders from which packets addressed to the multicast group 
address are eligible to be received during the prospective call, thereby effectively 
instructing the routers of the network to filter out traffic from source(s) other than 

30 the eligible senders. 
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In one embodiment, for example, as will be described in greater detail in 
relation to FIG. 3, the zone controller/RPEs specify only other zone 
controller/RPEs as valid senders so as to receive RSVP signaling and call 
admission control related traffic from other zone controller/RPEs while filtering 
5 out traffic from base stations, consoles, radio units, etc. In one embodiment, this 
is accomplished by the zone controller/RPEs issuing respective IGMPv3 
Membership Report messages (type=Mode_is_include) which includes a list of 
the source addresses for all the other zone controller/RPEs participating in the call 
(or optionally all the zone controller/RPEs in the system if the system is small). 

10 This IGMPv3 message will effectively tell the routers of the IP network to filter 
out all multicast bearer traffic from sources other than the zone controllers. 

Turning now to FIG. 2, there is shown a simplified packet-based 
communication system 200 useful for showing an RSVP message sequence 
between RPEs (e.g., RPE 1, RPE 2, RPE 3) in multiple zones (e.g. Zones 1-3) 

15 connected by packet network inter-zone links (e.g., LI, L2, L3). In one 

embodiment of the present invention, an RSVP message sequence is used to 
dynamically obtain reservations of bandwidth on one or more inter-zone links 
(e.g., LI, L3). The RSVP protocol itself is described in detail in IETF RFC 2205, 
incorporated herein by reference. 

20 As shown in FIG. 2, the RSVP message sequence is initiated by sourcing 

RPE 1 sending an RSVP "path" message202 its associated core router CR1. hi 
one embodiment, the path message 202 is addressed to a multicast group address 
that is to be used for a prospective communication. The routers of the network 
forward the path message 202 to participating RPEs (e.g., RPE 2 and RPE 3) 

25 having joined the multicast address. Thus, in the present example, the path 

message 202 is routed across the link LI to core router CR2 and across link L3 to 
core router CR3. In turn, CR2 and CR3 send the path message to RPE 2 and RPE 
3. 

Upon receiving the path message, RPE 2 and RPE 3 send RSVP "reserve" 
30 messages 204 back to RPE 1 , which reserve messages essentially retrace the path 
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as the path messages but in a reverse direction. Thus, in the present example, the 
reserve messages 204 are sent from RPE 2 to CR2 and from RPE 3 to CR3, then 
from CR2 to CR1 across the link LI and from CR3 to CR1 across the link L3 and 
finally from CR1 to RPE 1 . RPE 2 and RPE 3 receive confirmation from the 
5 network once the reservation is established. Thereafter, if bandwidth is available, 
the RPEs may set up a call between participating devices (in the case where the 
RPE resides within respective zone controllers, as will be described in FIG. 3). 
Alternatively, in the case where the RPEs reside within devices other than zone 
controllers, the RPEs may assist in setting up a call by informing their associated 

10 zone controllers that bandwidth is available for a prospective call and, having 
been informed of resource availability, the zone controller(s) set up the call. 

According to RSVP protocols, three types of reserve messages maybe 
used: Wildcard Filter (WF), Shared Explicit (SE) or Fixed Filter (FF), each of 
which will result in a specific type of data flow behavior as follows: 

1 5 The WF style allows the same resource reservation to be shared by 

multiple senders. Valid senders are not specified in the reservation. In effect, the 
reservation provides a shared pipe, whose size is determined by the largest 
reservation in the session, independent of the number and identity of the senders. 
Thus, for example, a reservation of bandwidth on link LI using the WF style 

20 would allow for any sending host (e.g., site router SRI or SR2) to use the 
reservation without RPE 2 having specified SRI or SR2 in the reservation. 

The SE style is similar to WF, except the receiver is allowed to specify 
which hosts are to be included in the reservation. Thus, for example, SRI and 
SR2 might be specified as eligible senders by RPE 2 using the SE style of reserve 

25 message. The SE style assumes multiple hosts will not send simultaneously. 
Thus, in the present example, the SE style of reservation might reserve a single 
call unit of bandwidth on link LI which is eligible for use by either SRI or SR2, 
but not SRI and SR2 simultaneously. 

The FF style creates distinct reservations for each sender in the session. 

30 Individual senders are specified in the reservation request message. Thus, for 
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example, if SRI, SR2 are specified as eligible senders by RPE 2, , the FF style of 
reservation might reserve two call units of bandwidth on link LI, i.e., one call unit 
of bandwidth for each of SRI, SR2, thereby allowing simultaneous use of link LI 
by both SRI and SR2. 
5 FIG. 3 shows steps performed by participating RPEs to set up a 

prospective multicast call according to one embodiment of the invention. The 
flow chart of FIG. 3 presumes that the RPEs reside within respective zone 
controllers and hence, perform call processing and mobility management 
functions as well as reservation proxy functions. However, as will be appreciated, 

10 similar functionality may be achieved by separate devices performing call 

processing and mobility management functions (i.e., where the RPEs and zone 
controllers are separate devices), assuming the RPEs are in communication with 
participating zone controllers. 

At step 302, a controlling zone controller/RPE receives a call request for a 

1 5 prospective call (e.g., a talkgroup call). The controlling zone controller may be 
statically configured or defined on a call by call basis (e.g., the zone controller of 
a sourcing zone). The call request may be received, for example, from a wireless 
communication device , such as a mobile or portable radio, wireline 
communication device, console (wireless or wireline), base station, site controller, 

20 comparator, telephone interconnect device or internet protocol telephony device; 
or, in the case where the call request is sourced from a zone other than that of the 
controlling zone controller, the call request may be forwarded to the controlling 
zone controller from a zone controller associated with the sourcing zone. 

For example, with reference to FIG. 1, controller 128 (zone 3) may receive 

25 a call request from communication unit 158, via base site 106 (not shown). If 
zone controller 128 is not the controlling zone controller, it forwards the call 
request to the controlling zone controller at step 302. For convenience, it is 
presumed for purposes of the present example that zone controller 128 is the 
controlling zone controller. 
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At step 304, the controlling zone controller/RPE determines zone locations 
of participating devices and IP addresses of their respective zone controllers. 
Thus, continuing the present example, controlling zone controller 128 (zone 3) 
may determine that the call involves communication units 156-157 (zone 2), 158- 
5 160 (zone 3) and 161-163 (zone 4). In such case, the zone controller 128 

determines that zone controllers 126 (zone 2) and 130 (zone 4) are participating 
zone controller/RPEs for the call (in addition to itself) and identifies the IP 
addresses of the participating zone controller/RPEs. 

At step 306, the controlling zone controller/RPE selects a multicast group 

1 0 address that is to be used for the call. In one embodiment, the multicast group 
address comprises an address that is to be used for exchanging control messages 
(e.g., call processing, mobility management and RSVP signaling) between 
participating zone controller/RPEs during call set-up, as described in relation to 
FIG. 3, and also to be used for communicating payload information between 

15 participating devices when the call is granted. However, according to principles 
of the present invention, the zone controller/RPEs may filter out the payload 
messages, as will be described. In a preferred embodiment, the controlling zone 
controller identifies the multicast group address dynamically, on a call-by-call 
basis. Alternatively, static multicast group addresses associated with various 

20 talkgroup IDs may be stored in memory and then recalled upon receiving a call 
request, as appropriate. 

In one embodiment, the multicast group address is communicated in either 
of two manners-to only the participating zone controller/RPEs or all zone 
controller/RPEs of the network. The controlling zone controller determines at 

25 step 308 whether to include only participating zones or all zones in the 
prospective call. 

If only participating zones are to be included, the controlling zone 
controller/RPE sends at step 310 the multicast group address to the participating 
zone controller/RPEs, which in effect instructs the RPEs to join the multicast 
30 group address to participate in the call. Alternatively, message(s) instructing the 
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participating zone controller/RPEs to join the selected multicast address may be 
sent separately from the message(s) informing them of the multicast address. 
Thereafter, at step 312, one or more of the participating zone controller/RPEs may 
specify a desired filtering of multicast packets for the call. In one embodiment, all 
5 of the participating zone controller/RPEs generate IGMPv3 multicast report(s) on 
the selected multicast address identifying interest in receiving multicast packets 
only from other participating zone controller/RPEs. In such manner, all of the 
zone controller/RPEs, upon joining the multicast address, will receive only control 
messages from the participating zone controller/RPEs and hence will not receive 

10 payload sourced from base stations or dispatch consoles in the participating zones. 
It should be noted, whereas the present invention provides for zone 
controllers/RPEs using IGMPv3 to specify desired filtering of multicast traffic, it 
is not necessary for other participating devices to use IGMPv3. System designers 
may employ IGMPv2 (which does not allow for devices to specify filtering) in 

15 devices (e.g., base stations) that are not desired to filter out payload or control 

messages from any source. Alternatively, IGMPv3 could be used in these devices, 
but generally that would require such devices to generate IGMPv3 reports 
specifying all sources as valid senders. IGMPv2 is preferred because it would 
allow such devices to receive packets from all senders by simply joining the 

20 multicast address without the need to generate any additional reports. 

If all zones are to be included, the controlling zone controller sends at step 
3 14 message(s) to all zone controller/RPEs of the network informing them of the 
selected multicast address and instructing them to join the multicast address to 
participate in the call. Thereafter, at step 316, one or more of the zone 

25 controller/RPEs may specify a desired filtering of multicast packets for the call, 
using IGMPv3 substantially as has been described in relation to step 312 to 
receive only control messages from the participating zone controller/RPEs when 
joined to the multicast address. 

At step 318, each zone controller/RPE having joined the multicast address 

30 sends an RSVP path message or other suitable control message destined to the 
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multicast group address. Upon reception of a path message, each zone 
controller/RPE responds at step 320 with an RSVP reserve message that 
essentially retraces the path of the received path message. The reserve message 
may incorporate the Wildcard Filter, Shared Explicit or Fixed Filter RSVP 
5 protocols, as described in relation to FIG. 2. In one embodiment, each reserve 
message requests confirmation from the network once the reservation is 
established. 

In the preferred embodiment, each participating zone controller/RPE sends 
both path messages and reserve messages so as to establish two reservations on 

10 the affected inter-zone links — one in each direction. Thus, new reservations do 
not need to be established when the sourcing site changes from one zone to 
another during the call. 

At step 322, the zone controller/RPE(s) determine an availability of 
communication resources (e.g., bandwidth) on the inter-zone links based on 

15 receiving (or not receiving) confirmation from the network that the appropriate 
reservation(s) are established for the prospective call. According to RSVP 
protocols, the receiving hosts (i.e., those sourcing RSVP reserve messages) 
request confirmation from the network as to the RSVP reservation availability. In 
the preferred embodiment, each participating zone controller/RPE acts as a 

20 receiving host, thus each participating zone controller/RPE receives confirmation 
from the network as to the availability of bandwidth on its requested link 
reservation(s). 

If bandwidth is available, the controlling zone controller/RPE grants the 
call at step 324. Otherwise, if bandwidth is not available, the call request is 
25 queued (or "busied") at step 326 and the controlling zone controller waits at step 
328 for a polling delay time or until other call ends, and the process returns to step 
318 to re-attempt a reservation of bandwidth for the call. 

FIG. 4 shows steps performed by a controlling zone controller/RPE upon 
end of a multicast call according to one embodiment of the invention. At step 
30 402, it is determined whether the call is ended. This may occur, for example, if no 
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call activity occurs for a designated "hang time" period, and/or upon receiving 
End of Call message(s) from certain hosts. For instance, continuing the example 
of FIG. 3, controlling zone controller 128 (zone 3) may receive an End of Call 
message from communication unit 158, via base site 106 (not shown). 
5 If the call is ended, the controlling zone controller instructs the 

participating devices to leave the multicast group at step 404, thereby causing the 
reservations to be torn down. As is well known, this may be accomplished by the 
participating devices sending IGMP "Leave" messages to their attached routers. 
The routers, in turn, de-establish the appropriate multicast routing trees based on 

1 0 the Leave messages. 

FIG. 5 shows steps performed by participating RPEs to add new 
participating zones to a multicast call in process according to one embodiment of 
the invention. The flow chart of FIG. 5, like FIG. 3, presumes that the RPEs 
reside within respective zone controllers and hence, perform call processing and 

15 mobility management functions as well as reservation proxy functions. However, 
as will be appreciated, similar functionality may be achieved by separate devices 
performing call processing and mobility management functions. 

At step 502, a controlling zone controller/RPE determines whether a new 
zone is to be added to a multicast call in process. This may occur, for example, 

20 upon the controlling zone controller receiving an affiliation message from a 

member of a talkgroup that has moved to a new zone during the talkgroup call, or 
from a zone controller of the new zone, as is known in the art. For instance, 
continuing the example of FIG. 3, controller 124 (zone 1) may receive an 
affiliation message from communication unit 156 (zone 2) moving to zone 1 

25 during the call, via a base site 106 of zone 1 . In such case, the controller 124 will 
forward the affiliation message or otherwise inform the controlling zone controller 
(e.g., controller 128, zone 3) of the new affiliation. The controlling zone 
controller 128 will determine that zone 1 needs to be added to the call in process 
because it wasn't included at the time of call set-up. The controlling zone 

30 controller 128 thereby determines that zone controller 124 (zone 1) is a new 
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participating device for the call and identifies the IP addresses of the new zone 
controller 128. 

At step 503, it is determined how multicast packets are presently being 
filtered for the call, i.e., whether participating zone controller/RPEs have 
5 specified, by IGMPv3 filtering, that packets may be received from all zone 

controllers, or only participating zone controllers of the system. If all zones are 
included, the process proceeds to step 508. If only participating zone controllers 
are presently included, the controlling zone controller instructs at step 504 the 
existing participating zone controller/RPEs to update their IGMPv3 filters to add 

10 the new zone. At step 506, the existing participating zone controllers (including 
the controlling zone controller) generate an IGMPv3 report message 
(Type=Allow_New_Sources) adding the new zone controller. Thus, in the 
present example, zone controller 128 instructs zone controllers 126 (zone 2) and 
130 (zone 4) to add zone controller 124 (zone 1) as a valid source of multicast 

15 traffic for the call at step 504, and the zone controllers 126, 128, 130 each 
generate an IGMPv3 report message adding zone controller 124 at step 506. 

At step 508, the controlling zone controller/RPE sends the multicast group 
address for the call to the zone controller/RPE of the new zone, which in effect 
instructs the new zone controller/RPE to join the multicast group address to 

20 participate in the call. Alternatively, message(s) instructing the new zone 
controller/RPE to join the multicast address may be sent separately from the 
message(s) informing it of the multicast address. Thereafter, at step 510, the new 
zone controller/RPEs may specify a desired filtering of multicast packets for the 
call. In one embodiment, this is accomplished by the new zone controller/RPE 

25 (e.g., zone controller 124, zone 1) generating IGMPv3 multicast report(s) on the 
indicated multicast address identifying interest in receiving multicast packets only 
from other participating zone controller/RPEs. In such manner, the new zone 
controller/RPE, upon joining the multicast address, will receive only control 
messages from the participating zone controller/RPEs and hence will not receive 

30 payload sourced from base stations or dispatch consoles in the participating zones. 
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At step 512, the new participating zone's RPE generates a RSVP PATH 
message on the indicated multicast group. In addition, the controlling zone's RPE 
generates a RSVP PATH message on the indicated multicast group. Generally, 
any originally-participating RPE may generate the second PATH message, but it is 
preferred that the second path message is generated by the controlling zone's RPE 
since it is the contoller of the group session. Thus, to add a new path, it is not 
necessary for all RPEs to generate a path message— just the new RPE and one 
other, preferably the controlling zone's RPE. Upon reception of a RSVP PATH 
message, each zone controller/RPE responds at step 514 with an RSVP RESV 
message that essentially retraces the path of the received RSVP PATH message. 
The reserve operation may incorporate the Wildcard Filter, Shared Explicit Filter 
or Fixed Filter RSVP protocols as described in relation to Fig. 2. 

At step 516, the zone controller/RPE(s) determine an availability of 
communication resources (e.g., bandwidth) on added link(s) to the new zone 
based on receiving (or not receiving) confirmation from the network that the 
appropriate reservation(s) are established for the call, substantially as described in 
relation to FIG. 3. If bandwidth is available, the controlling zone controller/RPE 
grants the call to the new zone at step 518. Otherwise, if bandwidth is not 
available, the user in the new zone is notified at step 326 and the new zone leaves 
the multicast group. The controlling zone controller and the new zone controller 
wait at step 522 for a polling delay time or until other call ends, and the process 
returns to step 510 to re-attempt a reservation of bandwidth for link(s) to the new 
zone. 

The present disclosure therefore identifies methods of call set-up and 
control in a packet-based communication system that rely upon reservation proxy 
elements (RPEs) establishing reservations of bandwidth over inter-zone links, 
which reservations maybe used by participating devices for active calls. 
Advantageously, the reservations are established on a call-by-call basis using 
RSVP signaling addressed to a multicast group address that is also used for the 
active calls. The RSVP signaling by RPEs, rather than participating endpoints, 
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reduces call set-up time and improves scalability of the communication system. 
Further, by providing for the RPEs to use IGMPv3 reports to specify valid 
senders, desired control traffic is received by the RPEs without receiving 
undesired payload traffic. 
5 The present invention may be embodied in other specific forms without 

departing from its spirit or essential characteristics. The described embodiments 
are to be considered in all respects only as illustrative and not restrictive. The 
scope of the invention is, therefore, indicated by the appended claims rather than 
by the foregoing description. All changes that come within the meaning and range 
10 of equivalency of the claims are to be embraced within their scope. 
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